Fm96.5 a Java-based Electronic Auction House

computational constructs in the interest of achieving a realistic {i.e., robust, thorough, lively and sound{ computational model. In particular, three basic implementation decisions were adopted from the start: All agent interactions were to be performed on a reliable network5 . Multithreading would be used to implement concurrency6 ; and Object encapsulation and strong typing would allow for layering and modularisation of the speci cation of agents and environment. In this version we chose to build internal (market) agents that correspond with actual sh market intermediaries. Thus our agents should be able to perform several functions {sometimes even in di erent scenes{ but should be able to manage precedence conditions and keep track of pending actions and obligations towards other agents. Although our emphasis in their construction has been functionality and performance, a certain degree of layering was brought to their design but no abstract reasoning was implemented7. The market boss, in FM96.5, thus, ful ls the prosaic function of a name server as well as the more anthropomorphic ones of auction supervisor and ultimate authority in the auction house. An auctioneer takes care of the bidding process. Two buyer intermediaries are deployed in this version: a buyer admitter who handles identity and acceptability conditions of buyer candidates, and a buyer manager who takes care of the nancial dealings and physical location of buyers. There are also two seller intermediaries, a seller admitter who registers sellers and goods, and a seller manager who settles the sellers' accounts after an auction. External (non-market) agents may be agents of arbitrary complexity, even human users, but they participate in the sh market always and exclusively through a standardized communication interface. Buyers in this version are handled through software incarnations of a remote control device which receives all the (signi cant) market illocutions, and transmits to the market only those illocutions that the buyer may express; always in a standardized form and only in scenes and moments when these illocutions are acceptable. Sellers, likewise, are always handled through similar nomadic interface-programs. Three market activities deserve special comment, for their treatment in FM96.5 has been signi cantly di erent from what we had done in previous versions: activation, closing and bidding rounds. In FM96.5, activation of the market is started by the market boss agent who opens the market place and establishes the identity of market intermediaries who are enabled by it to perform their intended functions 8. Once these intermediaries are activated, buyers and sellers may start entering those rooms where they would conduct business, but always subject to the sh market behaviour and illocutory constraints. In fact, as 5A network is said to be reliable if messages transmitted on it are never lost or duplicated, nor message sequencing altered (e.g. TCP/IP) [4]. 6In fact we used Java threads with their priority operators {aware of their implicit limitations. Cf. [6].7We use the term layering (as in [11]) to indicate that the internal architecture of agents involves various units that represent crisply di erentiated attitudes. 8In FM96.5 we still have a human user who triggers an activation command through which the market boss agent is spawned and starting conditions for an auction {including number of sellers, products and product characteristics{ are passed. soon as the market intermediaries are activated, they set up an agenda of pending actions that will correspond to sequential or concurrent actions (threads) they have the obligation to perform. These agendas are constantly updated since obligations are ful lled by the market agents and new actions may be inscribed in the agenda by a directive of the market boss {for example: open a bidding round{, by a request from an external agent {e.g. update my credit line{ or by a delegation from another market intermediary {e.g. check buyer's credit status. In this way activity is propagated to di erent scenes through events that are triggered sometimes by the market boss, sometimes by other market agents, but many times by sellers or buyers as well. Market closing involves, also, some arti ciality in FM96.5. The market boss may stop an auction through a closing declaration {whose triggering conditions are explicit, albeit varied{ but actual closing requires that all pending actions of market agents be properly terminated. Depending on the prevalent situation of the market at the time of the closing declaration, the termination process may be more or less involved. In order to avoid anomalous conditions, some careful bookkeeping of delegation of execution control and of action ow had to be implemented9. Likewise, the implementation of the sh market's downward bidding protocol (as shown in Fig. 2 and Fig. 1) has been revised considerably. In this new version, synchronism is achieved not within each price quote {as in the actual sh market room{ but within the sequence of price quotations that are needed to sell one good10. By doing so, and thanks to the fact that a reliable network is assumed, fairness conditions are preserved. Thus, premature bids, foot-dragging, and spoo ng are adequately avoided directly by the protocol implementation, while malicious suplantation and snooping are dealt with through ad-hoc identity devices. 3 Design Issues For FM96.5 we had two complementary objectives in mind. First of all we wanted a robust, stable version of the sh market that we could expand or re ne in a modular fashion in order to develop and test, systematically, our theoretical proposals on agent architecture, agent models, interaction protocols and structured environments. But we also wanted a realistic example of an electronic auction house that could eventually be developed into a commercially interesting product. Therefore, the guiding principles had to do with transparency, modularity, reusability and standardization on one hand, and, on the other, robustness, functionality and performance. Evidently, the choice of tools and programming methodology was strongly determined by these principles. First, there was the matter of computing paradigm: Illocutions can be regarded as the basic unit of analysis in the Fishmarket. In the actual-world sh market, these illocutions are performed by humans with some intention in mind and eventually change the state of the world in a way analogous to the way physical actions do (cf. e.g. [15]). In the electronic Fishmarket, an agent performing an illocution can be computationally modelled as a client (speaker) contacting a server (receiver) and sending a message (illocution). In the same way, an agent listening to an illocution (message) can be seen as a server (receiver) 9FM96.5 is not provably fault-tolerant yet, but signi cant security, integrity and failure-recovery features are built-in for that purpose. 10That (complete) sequence is called a bidding round in this paper. waiting for incoming communication requests from a client, performing the necessary computation (which eventually changes the state of the world) and perhaps returning an answer to the client. Note that this client/server model is a computational model and is independent of the type of illocution. The fact that every illocution changes in some way or another the state of the receiver justi es this very convenient implementational simpli cation11. Among the competing paradigms (and technologies) for developing new client-server applications, distributed objects seem to be the leading force. Nonetheless, even though we do like the many bene ts of distributed objects, we do not believe that such a paradigm is the most suitable for modelling the type of agent interactions present within the Fishmarket12. In the actual sh market, buyers, sellers and market intermediaries utter illocutions that trigger actions on the hearers. But it is important to notice that the di erent behaviours exhibited by the hearers are exclusively determined by themselves as a response to incoming messages. From a computational point of view, all we need, then, is to bundle clients (speakers) messages and send them out, and it should be up to servers (hearers) to determine how to handle incoming messages. We see no bene t from endowing agents with the capability to invoke methods on remote objects since we do not intend that clients trigger actions on the servers' side but only that they provoke actions to be triggered. Therefore, we prefer the model of clients' illocutions triggering actions in the server, in contrast to clients invoking those actions directly. And then there is the matter of concurrence: One of the main features of the sh market is that it is composed of several, isolated scenes whose activities happen in a concurrent way. But, notably, market intermediaries may be involved in tasks that happen (simultaneously) in di erent scenes, (as depicted in Fig. 2). We modelled scenes as sets of distributed processes and gave to our market agents a multi-threaded architecture so they are capable of both servicing requests and delegating tasks concurrently. For instance, the buyers' manager may be active enrolling several buyers in its list of buyers while at the same time be involved in verifying whether a bid made in the current bidding round should be regarded as legal. Hence, we in fact model two levels of concurrence. On one hand, that corresponding to the concurrent activity of isolated scenes, modelled as a set of distributed processes. And on the other hand, the inner activity of each market agent, modelled as a multi-threaded process. Consequently, actionow in the Fishmarket is non-trivial. One should distinguish an agentow corresponding to buyers and sellers moving from scene to scene, and a communicationow caused by illocutions exchanged between agents. In order to model the mobility of buyers and sellers, we designed our scenes as virtual scenes made up of processes that might physically be running at di erent sites but which are always virtually situated within the same scene. Buyers and sellers in FM96.5 have therefore the impression of moving among scenes (e.g. from the admission o ce to the auction 11Two technicalities may be worth noting. First, this simpli cation imposes processing costs: A cost is paid in the interpretation of the illocution on the server side {di erent illocutions trigger possibly di erent actions in the server{ and another cost had to be paid at the client side in order to produce the utterance of the illocution. Second, a true client/server model usually implies an explicit response from the server to every request from a client. In FM96.5, for performance and transparency reasons, we actually build in a few illocution/action sequences in which servers give no explicit replies. But, these are all reifyable as true client/server interactions. 12It will be evident when we discuss the external agents' nomadic agent interfaces that the distributed object approach is indeed quite useful for those devices. Figure 1: The Fishmarket naive downward bidding protocol. Figure 2: The Fishmarket downward bidding protocol. Naive communication ow. room, from there to the settlements o ce and so on) in the same way human buyers and human sellers would in the actual sh market. As to the communication ow, we opted for standardizing the structure of the messages being exchanged between agents. Each message is regarded as a Java object containing a tag, information about the sender and the contents of the message, which is in turn a Java object. The use of Java Object Serialization [25] allowed for serializing each message at the sender side and deserializing it at the receiver side in a straightforward way. And nally, external agent interfaces: In order to achieve the most realistic implementation of the auction house activity, we decided to standardize as much as possible all conceivable external agent interactions with the market. We took advantage of the highly structured negotiation convention of auctions, and of the fact that in actual sh markets all bidding round interactions can be mediated through a remote control device. Thus, we built nomadic agent interfaces {a sort of electronic remote control devices{ that could be used as universal interfaces by buyer and seller agents. This nomadic interface is installed in the external agent's computer and becomes the only channel through which messages can pass between external agents and market (internal) agents. Since the Fishmarket interactions are all linked to illocutions, this interface is all that is needed, in principle, to participate e ectively in the electronic auction house. But in fact, these interfaces ful l other necessary duties as well: they sustain the identity of participants, validate illocution emission and reception, and, generally speaking, enforce the auction-house rules {including the bidding protocol13. It should be noted, then, that in FM96.5 there are really no buyer or seller agents, only their nomadic interfaces. But through these nomadic interfaces buyer and seller agents {developed and owned elsewhere or even human buyers or sellers{ can participate in electronic auctions. This is, we think, the kind of design Castelfranchi was suggesting : "...arti cial agents can be designed, and they should be designed as rational. But they should also be integrated into human organisations, and be capable to interact with their human partners in an adaptive and understandable way." [2]. In our choice of tools, we pro ted from our previous experiences too. Having already developed prototypes using PVM and MPI for internetworking and C and EU-Lisp for other features, Java suggested relevant advantages [6] that were worth testing in the Fishmarket implementation: Java provides the advantages of object-oriented languages (reusability, modularity, encapsulation, etc.) and claims to be designed for maximum portability. Its ease of programming and safety features help produce debugged code quickly. Java is reported to be valuable for distributed network environments. 13Obviously, this interface permits to address the security issues that would arise when arbitrary foreign agents (i.e. whose code we do not know) are admitted into the Fishmarket. In fact the nomadic quality of the interface makes it possible for other external agents {and necessary for the agent who uses it{ to prove a zero-information property, i.e. that through the interface no information of the market, nor any information of the external agent can be transferred outside the interface, except for the one that is explicitly stated by the interface. Note also that our nomadic interfaces are akin to the payment and service cassettes used in the construction of the Java Wallet (cf. [24]), and can in fact be readily connected to them.